home *** CD-ROM | disk | FTP | other *** search
-
- INTERIM_MEETING_REPORT_
-
-
- Reported by Dave Crocker/TBO
-
- Minutes of the IP Address Encapsulation Working Group (IPAE)
-
- This meeting was held at Sun Microsystems on October 8, 1992
-
- The major topic of the meeting has been documented in a note sent by Bob
- Hinden, concerning a change to the IPAE header, to make it be the same
- as the SIP header. (i.e., make IPAE = IP+SIP, plus transition rules.)
- This was a somewhat unexpected turn of events, except in hindsight. A
- number of forces seem to have been moving us in this direction and there
- was a very strong feeling, by the end of the meeting, that this change
- vastly cleans up the entire scenario for the Internet, giving it the
- least transition pain and the most amenable longer-term protocol, since
- it is the closest to current IP AND it has a mechanism for adding new
- services (via its own mini-layer.)
-
-
- Reminder: SIP has a mailing list. To join, send to:
- sip-request@caldera.usc.edu
-
-
-
- Two other items were covered:
-
- ICMP
-
- The 64-bit data limit for ICMP continues to be a problem. We discussed
- more about the handling of ICMP messages sent by interior, unmodified
- routers, which therefore contain only the within-commonwealth IP
- addresses of the interior router and the border IPAE router and don't
- have the full IPAE address of the originating host available.
-
- We had generally believed that this was an unfortunate, but not serious,
- problem. It was then observed that it _is_ a significant problem for
- MTU Discovery. The originating host really does need to get the ICMP
- feedback.
-
- We adopted the framework that a commonwealth which does IPAE/IP
- tunneling -- i.e., the interior routers are not IPAE knowledgeable --
- can be viewed much the same as IP over X.25, with the border routers
- treating the commonwealth as an underlying data-link environment.
- Hence, feedback from interior routers is like feedback from interior
- X.25 packet switches. We would not expect those raw messages to be
- forwarded back to the originating host.
-
- We would expect the border routers to record the feedback and translate
- it. In this case, this means that the border router needs to cache MTU
- information about IP addresses inside its commonwealth. When it gets an
- IPAE datagram, it needs to check its size against the cache (cache =
- dest IP addr + MTU) and either fragment the datagram or send back an
-
- 1
-
-
-
-
-
- ICMP Too Big.
-
- Basic language for the spec is: IPAE routers which are the IP
- recipients of IP/ICMP messages must cache ``Can't Fragment'' (``Too
- Big'').
-
- Router Table Size
-
- We did an extended case analysis of the current and projected sizes for
- 3 different router tables: The Source Information Base is the raw stuff
- that comes in from the routing protocol(s). The Real-Time Table is used
- for doing that actual data-handling of actual packets. The Policy table
- is whatever set of contingent rules are needed to turn the first table
- into the second. I have intentionally not used more typical terms for
- the tables, since we ran into some nomenclature confusion during the
- discussion.
-
- Note that the IPAE secton is divided into two, since the border routers
- need to maintain a set of IPAE routing tables as well as a set of IP
- routing tables (for the commonwealth.)
-
-
-
- SOURCE INFO BASE REAL-TIME TABLE POLICY
-
- (Variable, xmit (Variable, compute (Static)
- + storage overhead) + storage overhead)
-
- Now: All nets*neighbors All nets All nets
-
-
- IPAE: (Same as Source All nets
- Info Base, but (includes the
- IP: Attached cwlth without the IPAE/IP address
- nets "* neighbors" map needed during
- component) transition while
- IPAE: CWlth hierarchy, IP addresses
- only as needed. are still unique)
- (e.g., [all
- countries
- + attached
- metro/provider]
- * neighbors)
-
-
-
- 2
-